Data Feedback loop for medical therapy adjustment

ABSTRACT

An implementation of a technology, described herein, for implantable medical therapy devices and techniques related to gathering and processing data field-collected by such implantable medical therapy devices. With an ICTD system and a central database, at least one embodiment of the invention, described herein, collects and analyzes data—which includes historical cardiac-status-and-treatment information—for a specific patient and adjusts a patient&#39;s therapy accordingly. With an ICTD system and a central database, at least one embodiment of the invention, described herein, collects and analyzes data—which includes historical cardiac-status-and-treatment information—for a patient population and adjusts a patient&#39;s therapy accordingly. This abstract itself is not intended to limit the scope of this patent. The scope of the present invention is pointed out in the appending claims.

TECHNICAL FIELD

This invention generally concerns implantable medical therapy devicesand techniques related to gathering and processing data field-collectedby such implantable medical therapy devices.

BACKGROUND

Implantable cardiac therapy devices (ICTDs) are implanted within thebody of a patient to monitor, regulate, and/or correct heart function.ICTDs include implantable cardiac stimulation devices (e.g., implantablecardiac pacemakers, implantable defibrillators) that apply stimulationtherapy to the heart as well as implantable cardiac monitors thatmonitor heart activity.

ICTDs typically include a control unit positioned within a casing thatis implanted into the body and a set of leads that are positioned toimpart stimulation and/or monitor cardiac activity. With improvedprocessor and memory technologies, the control units have becomeincreasingly more sophisticated, allowing them to monitor many types ofconditions and apply tailored stimulation therapies in response to thoseconditions.

ICTDs are typically capable of being programmed remotely by an externalprogramming device, often called a “programmer”. Today, individual ICTDsare equipped with telemetry circuits that communicate with theprogrammer. One type of programmer utilizes an electromagnetic wand thatis placed near the implanted cardiac device to communicate with theimplanted device. When used in a sterile field, the wand may be enclosedin a sterile sheath. The wand contains a coil that forms a transformercoupling with the ICTD telemetry circuitry. The wand transmits lowfrequency signals by varying coil impedance.

Early telemetry systems were passive, meaning that the communication wasunidirectional from the programmer to the implanted device. Passivetelemetry allowed a treating physician to download instructions to theimplanted device following implantation. Due to power and sizeconstraints, early commercial versions of the implanted devices wereincapable of transmitting information back to the programmer.

As power capabilities improved, active telemetry became feasible,allowing synchronous bi-directional communication between the implanteddevice and the programmer. Active telemetry utilizes a half-duplexcommunication mode in which the programmer sends instructions in apredefined frame format and, following termination of this transmission,the implanted device returns data using the frame format. With activetelemetry, the treating physician is able to not only program theimplanted device, but also retrieve information from the implanteddevice to evaluate heart activity and device performance. The treatingphysician may periodically want to review device performance or heartactivity data for predefined periods of time to ensure that the deviceis providing therapy in desired manner. Consequently, current generationimplantable cardiac therapy devices incorporate memories, and theprocessors periodically sample and record various performance parametermeasurements in the memories.

Data pertaining to a patient's cardiac condition is gathered and storedby the programmer during programming sessions of the ICTDs. Analysis ofthe cardiac condition is performed locally by the programming software.Programmers offer comprehensive diagnostic capabilities, high-speedprocessing, and easy operation, thereby facilitating efficientprogramming and timely patient follow-up.

In addition to local analysis, TransTelephonic Monitoring (TTM) systemsare employed to gather current cardiac data from patients who are remotefrom the healthcare provider. TTM systems are placed in patients' homes.They typically include a base unit that gathers information from theICTD much like the programmer would. The base unit is connected to atelephone line so that data may be transmitted to the medical staffresponsible for that patient. An example of an ICTD TTM system is aservice from St. Jude Medical® and Raytel® Cardiac Services called“Housecall™.” This service provides current programmed parameters andepisode diagnostic information for a plurality of events includingstored electrograms (EGMs). Real-time EGMs with annotated statusinformation can also be transmitted.

Using a telephone and a transmitter, the TTM system provides both themedical staff and the patient the convenience of instant analysis oftherapy without having the patient leave the comfort of home. Typically,real-time measurements are transmitted in just minutes. Patients may beclosely monitored, and the medical staff has more control of theirpatient's treatment, thus administering better patient management.

One challenge that still persists, however, is how to efficiently andeffectively present patient information and cardiac data to medicalpersonnel and other knowledge workers who might have an interest in thedevice data. People utilize different types of computing devices toreceive and view data, such as computers, portable computers, personaldigital assistants, facsimile machines, and so on. These computingdevices have different user interface capabilities and features.Accordingly, there is a need for a system that delivers the data to awide variety of computing devices.

On an individual patient basis, there is no existing comprehensive andpersistent mechanism for gathering long-term and real-time data. WhileICTDs perform short-term monitoring and recording patient cardiacfunction, their relatively small processing and memory capabilitieslimit the thorough analysis, and action thereupon, of this data,particularly in the long term. Therefore, there is no existing mechanismfor collecting data that includes long-term cardiac monitoring andtreatment information of specific patients and other medical anddemographic information of specific patients.

Although the TTM systems do monitor and transmit data for a specificpatient, this data is not collected and stored in the ICTD itself in amanner that is persistent. Since there is limited memory capacity on theICTD, the collected data is routinely wiped out of the ICTD's memory(typically, upon programming).

Generally, the ICTD does not analyze such data to automatically adjustpatient therapy. While the ICTD may monitor some functions, suchmonitoring does not result in reprogramming the ICTD. Most conventionaltherapies monitor the patient and act upon the present circumstances,but do not change their function over the long term.

In addition, this data is not transmitted to a central database where itis analyzed to determine if a therapy adjustment is desirable; and ifso, automatically indicating and reprogramming the ICTD to adjust thetherapy accordingly.

On a basis of a patient population, there is no existing mechanism forgathering long-term and real-time data. There is no existing mechanismfor collecting data that includes cardiac monitoring and treatmentinformation of a patient population and other medical and demographicinformation of a patient population.

Although the TTM systems do monitor and transmit data for a specificpatient, the data is not collected and stored regarding a patientpopulation. With existing techniques and systems, patient populationdata is not used to set “factory defaults” in the ICTD itself or theICTD system itself. Conventionally, the ICTD does not use informationderived from such patient population data to adjust patient therapy.Furthermore, with traditional techniques, patient population data is notanalyzed to determine if therapy adjustment is desirable for a specificpatient.

One challenge that still persists, however, is how to collect andanalyze data—which includes historical cardiac-status-and-treatmentinformation—for a specific patient and to adjust a patient's therapyaccordingly. Likewise, there is a challenge to collect and analyzedata—which includes historical cardiac-status-and-treatmentinformation—for a patient population and to adjust a patient's therapyaccordingly.

SUMMARY

Described herein is a technology for implantable medical therapy devicesand techniques related to gathering and processing data field-collectedby such implantable medical therapy devices.

With an ICTD system and a central database, at least one embodiment ofthe invention, described herein, collects and analyzes data—whichincludes historical cardiac-status-and-treatment information—for aspecific patient and adjusts a patient's therapy accordingly. With anICTD system and a central database, at least one embodiment of theinvention, described herein, collects and analyzes data—which includeshistorical cardiac-status-and-treatment information—for a patientpopulation and adjusts a patient's therapy accordingly.

This summary itself is not intended to limit the scope of this patent.Moreover, the title of this patent is not intended to limit the scope ofthis patent. For a better understanding of the present invention, pleasesee the following detailed description and appending claims, taken inconjunction with the accompanying drawings. The scope of the presentinvention is pointed out in the appending claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Generally, the same numbers are used throughout the drawings toreference like elements and features. Further features and advantages ofthe claimed embodiments can be more readily understood by reference tothe following description taken in conjunction with the accompanyingdrawings.

FIG. 1 is a diagrammatic illustration of a cardiac therapy networkarchitecture with an implantable cardiac therapy device (ICTD) connectedto a network of computing systems used by various knowledge workers.

FIG. 2 is a functional diagram illustrating information flow from theICTD to the computing systems associated with the knowledge workers.

FIG. 3 is a functional diagram illustrating how the various computingsystems share pieces of information to improve care given to thepatient.

FIG. 4 is a functional diagram illustrating a patient feedbackarchitecture and the information flow from the computing systems back tothe ICTD.

FIG. 5 is a simplified illustration of an ICTD in electricalcommunication with a patient's heart for monitoring heart activityand/or delivering stimulation therapy.

FIG. 6 is a functional block diagram of an exemplary implantable cardiactherapy device.

FIG. 7 is a functional block diagram of an exemplary computing devicethat may be used in the computing systems of the cardiac therapy networkarchitecture.

FIG. 8 is a flow diagram that describes a methodological implementationin accordance with one embodiment.

DETAILED DESCRIPTION

In the following description, for purposes of the explanation, specificnumbers, materials and configurations are set forth in order to providea thorough understanding of the present invention. However, it will beapparent to one skilled in the art that the present invention may bepracticed without the specific exemplary details. In other instances,well-known features are omitted or simplified to clarify the descriptionof the exemplary implementations of present invention. Furthermore, forease of understanding, certain method steps are delineated as separatesteps; however, these separately delineated steps should not beconstrued as necessarily order dependent in their performance.

The following description sets forth one or more exemplaryimplementations of a Data Feedback Loop for Medical Therapy Adjustmentthat incorporate elements recited in the appended claims. Theseimplementations are described with specificity in order to meetstatutory written description, enablement, and best-mode requirements.However, the description itself is not intended to limit the scope ofthis patent.

Overview

The one or more exemplary implementations, described herein, of thepresent invention may be implemented (in whole or in part) by anexemplary cardiac therapy network architecture 100 like that shown inFIG. 1.

With at least one embodiment, the exemplary feedback loop technologycollects and analyzes data—which includes historicalcardiac-status-and-treatment information—for a specific patient andadjusts a patient's therapy accordingly. Rather than retaining historyof a patient from a programming session or a collection of suchsessions, the patient-specific data is collected over the lifetime ofthe patient—as long as the patient has an ICTD implanted therein. Thisdata is “field-collected.” At least in part, this means that the data iscollected outside of a laboratory or office-type setting.Field-collected data is obtained while the patient goes about theirnormal activities.

With at least one embodiment, the exemplary feedback loop technologycollects and analyzes data—which includes historicalcardiac-status-and-treatment information—for a patient population andadjusts a patient's therapy accordingly. Rather than retaining historyof a single patient from a single programming session or a collection ofsuch sessions for a single patient, the patient-population data iscollected over the lifetime of a population of patients. This data isalso “field-collected.”

In other words, the technology described herein provides a personalizedclosed-feedback loop for individual patients and/or a generalizedclosed-feedback loop for patient populations. With the personalizedloop, a patient's treatment is automatically adjusted, or recommended tobe adjusted, based upon the patient's own medical history (includingcardiac monitoring and response to cardiac treatment) and other personaldata. With the generalized loop, a patient's treatment is automaticallyadjusted based upon the medical history (including cardiac monitoringand response to cardiac treatment) and other personal data of a patientpopulation-particularly where correlations exist between the subjectpatient and those in the population.

Cardiac Therapy Network

FIG. 1 shows an exemplary cardiac therapy network architecture 100 thatincludes an implantable cardiac therapy device (ICTD) 102 coupled to anetwork of computing systems associated with various knowledge workerswho have interest in cardiac therapy. The ICTD is illustrated as beingimplanted in a human patient 104. The ICTD 102 is in electricalcommunication with a patient's heart 106 by way of multiple leads 108suitable for monitoring cardiac activity and/or delivering multi-chamberstimulation and shock therapy.

The ICTD 1 02 may communicate with a standalone or offline programmer110 via short-range telemetry technology. The offline programmer 110 isequipped with a wand that, when positioned proximal to the ICTD 102,communicates with the ICTD 102 through a magnetic coupling.

The ICTD 102 can alternatively, or additionally, communicate with alocal transceiver 112. The local transceiver 112 may be a device thatresides on or near the patient, such as an electronic communicationsdevice that is worn by the patient or is situated on a structure withinthe room or residence of the patient. The local transceiver 112communicates with the ICTD 102 using short-range telemetry orlonger-range high-frequency-based telemetry, such as RF (radiofrequency) transmissions. Alternatively, the local transceiver 112 maybe incorporated into the ICTD 102, as represented by dashed line 111. Inthis case, the ICTD includes a separate and isolated package area thataccommodates high-frequency transmissions without disrupting operationof the monitoring and stimulation circuitry.

Depending upon the implementation and transmission range, the localtransceiver 112 can be in communication with various other devices ofthe network architecture 100. One possible implementation is for thelocal transceiver 112 to transmit information received from the ICTD 102to a networked programmer 114, which is connected to network 120. Thenetworked programmer 114 is similar in operation to standaloneprogrammer 110, but differs in that it is connected to the network 120.The networked programmer 114 may be local to, or remote from, the localtransceiver 112; or alternatively, the local transceiver 112 may beincorporated into the networked programmer 114, as represented by dashedline 116.

Another possible implementation is for the local transceiver to beconnected directly to the network 120 for communication with remotecomputing devices and/or programmers. Still another possibility is forthe local transceiver 112 to communicate with the network 120 viawireless communication, such as via a satellite system 122.

The network 120 may be implemented by one or more different types ofnetworks (e.g., Internet, local area network, wide area network,telephone, cable, satellite, etc.), including wire-based technologies(e.g., telephone line, cable, fiber optics, etc.) and/or wirelesstechnologies (e.g., RF, cellular, microwave, IR, wireless personal areanetwork, etc.). The network 120 can be configured to support any numberof different protocols, including HTTP (HyperText Transport Protocol),TCP/IP (Transmission Control Protocol/Internet Protocol), WAP (WirelessApplication Protocol), Bluetooth, and so on.

A number of knowledge workers are interested in data gathered from theimplantable cardiac therapy device 102. Representative knowledge workersinclude healthcare providers 130, the device manufacturer 132, clinicalgroups 134, and regulatory agencies 136. The knowledge workers areinterested in different portions of the data. For instance, thehealthcare providers 130 are interested in information pertaining to aparticular patient's condition. The manufacturer 132 cares about how thedevice is operating. The clinical groups 134 want certain data forinclusion in patient populations that can be studied and analyzed. Theregulatory agencies 136 are concerned whether the devices, and varioustreatments administered by them, are safe or pose a health risk.

The network architecture 100 facilitates distribution of the device datato the various knowledge workers. Information gathered from the deviceis integrated, processed, and distributed to the knowledge workers.Computer systems maintain and store the device data, and prepare thedata for efficient presentation to the knowledge workers. The computersystems are represented pictorially in FIG. 1 as databases. However,such system can be implemented using a wide variety of computingdevices, ranging from small handheld computers or portable digitalassistants (PDAs) carried by physicians to workstations or mainframecomputers with large storage capabilities. The healthcare providers 130are equipped with computer systems 140 that store and process patientrecords 142. The manufacturer 132 has a computer system 144 that tracksdevice data 146 returned from ICTDs 102. The clinical groups 134 havecomputer systems 148 that store and analyze data across patientpopulations, as represented by a histogram 150. The regulatory agencies136 maintain computer systems 152 that register and track healthcarerisk data 154 for ICTDs.

The network architecture 100 supports two-way communication. Not only isdata collected from the ICTD 102 and distributed to the various computersystems of the knowledge workers, but also information can be returnedfrom these computer systems to the networked programmer 114 and/or thelocal transceiver 112 for communication back to the ICTD 102.Information returned to the ICTD 102 may be used to adjust operation ofthe device, or modify therapies being applied by the device. Suchinformation may be imparted to the ICTD 102 automatically, without thepatient's knowledge.

Additionally, information may be sent to a patient notification device160 to notify the patient of some event or item. The patientnotification device 160 can be implemented in a number of waysincluding, for example, as a telephone, a cellular phone, a pager, a PDA(personal digital assistant), a dedicated patient communication device,a computer, an alarm, and so on. Notifications may be as simple as aninstruction to sound an alarm to inform the patient to call into thehealthcare providers, or as complex as HTML-based pages with graphicsand textual data to educate the patient. Notification messages sent tothe patient notification device 160 can contain essentially any type ofinformation related to cardiac medicinal purposes or device operation.Such information might include new studies released by clinical groupspertaining to device operation and patient activity (e.g., habits,diets, exercise, etc.), recall notices or operational data from themanufacturer, patient-specific instructions sent by the healthcareproviders, or warnings published by regulatory groups.

Notifications can be sent directly from the knowledge worker to thepatient. Additionally, the network architecture 100 may include anotification system 170 that operates computer systems 172 designed tocreate and deliver notification messages 174 on behalf of the knowledgeworkers. The notification system 170 delivers the messages in formatssupported by the various types of patient notification devices 160. Forinstance, if the patient carries a pager, a notification message mightconsist of a simple text statement in a pager protocol. For a moresophisticated wireless-enabled PDA or Internet-oriented cellular phone,messages might contain more than text data and be formatted using WAPformats.

FIG. 2 shows the flow of data from the implantable cardiac therapydevice 102 to the various computer systems used by the knowledgeworkers. Data from the ICTD is output as digital data, as represented bythe string of 0's and 1's. The data may consist of any number of items,including heart activity (e.g., ECG), patient information, deviceoperation, analysis results from on-device diagnostics, and so on.

A data integrator 200 accumulates the data and stores it in a repository202. A processing system 204 processes portions of the data according tovarious applications 206 that are specifically tailored to place thedata into condition for various knowledge workers. For example,healthcare workers might be interested in certain portions of the data,such as the ECG data and the patient information. Clinical scientistsmight be interested in the heart data, but do not wish to see anypatient information. Manufacturers may be interested in the raw datastream itself as a tool to discern how the device is operating.Depending on the needs of the end worker, the processing system 204takes the raw device data, evaluates its accuracy and completeness, andgenerates different packages of data for delivery to the variousknowledge workers. The processed data packages are also stored in therepository 202.

When the data is ready for delivery, a distribution/presentation system208 distributes the different packages to the appropriate computersystems 140,144,148, 152, and 172. The distribution/presentation system208 is configured to serve the packages according to the protocols andformats desired by the computer systems. In this manner, the networkarchitecture 100 allows relevant portions of device data, collected fromthe ICTD, to be disseminated to the appropriate knowledge workers in aform they prefer.

Once the ICTD data is delivered, the computer systems 140, 144, 148,152, and 172 store the data and/or present the data to the knowledgeworker. The computer systems may perform further processing specific totheir use of the data. Through these processes, the knowledge workerscreate additional information that is useful to the patient, or otherknowledge workers with interests in ICTDs. For example, from the ICTDdata, the knowledge workers might devise improved therapies for a givenpatient, or create instructions to modify operation of a specific ICTD,or gain a better understanding of how implantable cardiac devicesoperate in general, or develop better technologies for futuregenerations of ICTDs. Much of this created knowledge can be shared amongthe various knowledge workers.

FIG. 3 shows how the various computing systems 140, 144, 148, 152, and172 can cooperate and share pieces of information to improve the caregiven to a patient. Where appropriate and legally acceptable, thecomputer systems may be configured to pass non-private information amongthe various knowledge workers to better improve their understanding ofthe implantable medical field. Clinical results 150 produced by theclinical computer systems 148 may be shared with healthcare providers toimprove patient care or with manufacturers to help in their design ofnext generation devices. The sharing of information may further lead tobetter and timelier healthcare for the patients.

If the collective knowledge base produces information that may provehelpful to the patient, that information can be passed to thenotification system 172 for delivery to one or more patients. Also, anyone of the knowledge workers may wish to employ the notification system172 to send messages to the patient(s).

Patient Feedback Architecture

FIG. 4 shows the patient feedback architecture 400. It also shows, inmore detail, the flow of information back from the various computersystems used by the knowledge workers to the implantable cardiac therapydevice 102; the patient notification device 160 or back to the devicemanufacturer 132.

Information from any one of the computing systems—healthcare computersystem(s) 140, manufacturer computer system(s) 144, clinical computersystem(s) 148, regulatory computer system(s) 152—or the notificationsystem 172 can be sent to a patient feedback system 410.

As shown by arrows between the patient feedback system 410 and dashedbox 420, the system 410 facilitates delivery of the information back tothe patient. As shown by arrows between the patient feedback system 410and dashed box 430, the system 410 facilitates delivery of theinformation back to the device manufacturer 132.

The patient feedback system may be an independent system, orincorporated into one or more of the computing systems. It mayalternatively be integrated into the notification system 172.

The patient feedback system 410 may be implemented in many ways. As oneexemplary implementation, the patient feedback system 410 is implementedas a server that serves content back to the networked programmer 114,which then uses the information to program the ICTD 102 through a builtin transceiver 116, local transceiver 112, or wand-based telemetry. Asanother possible implementation, the patient feedback system may be acellular or RF transmission system that sends information back to thepatient feedback device 160.

The network architecture 100 facilitates continuous care around theclock, regardless of where the patient is located. For instance, supposethe patient is driving in the car when a cardiac episode occurs. TheICTD 102 detects the condition and transmits an alert message about thecondition to the local transceiver 112. The message is processed anddelivered to a physician's computer or PDA via the network 120. Thephysician can make a diagnosis and send some instructions back to thepatient's ICTD. The physician might also have a notification messagethat guides the patient to a nearest healthcare facility for furthertreatment sent via the notification system 170 to the patient'snotification device 160. Concurrently, the physician can share thepatient's records online with an attending physician at the healthcarefacility so that the attending physician can review the records prior tothe patient's arrival.

With the patient feedback architecture 400, the patient feedback system410 collects data for a specific patient. The patient feedback system410 may process such data. The system may transmit such data to anothercomponent, such as the networked programmer 114, for processing oradditional processing of the data.

The patient feedback system 410 (or another component) may determine achange in therapy for the specific patient based upon data gathered fromthat patient. The determination may be noted and documented. It may betransmitted to the patient notification device 160. It may betransmitted to the networked programmer 114.

Furthermore, the change of therapy may be made automatically bycommunicating to the ICTD 102 via the local transceiver 112 or othersuch mechanisms.

Alternatively, with the patient feedback architecture 400, the patientfeedback system 410 collects data for a patient population (i.e., morethan one patient). The patient feedback system 410 may process suchdata. The system may transmit such data to another component, such asthe networked programmer 114, for processing or additional processing ofthe data.

The patient feedback system 410 (or another component) may determine achange in therapy for the specific patient based upon data from apatient population. The determination may be noted and documented. Itmay be transmitted to the patient notification device 160. It may betransmitted to the networked programmer 114.

Furthermore, the change of therapy may be made automatically bycommunicating to the ICTD 102 via the local transceiver 112 or othersuch mechanisms.

More alternatively still, with the patient feedback architecture 400,the patient feedback system 410 collects data for a patient population(i.e., more than one patient). The patient feedback system 410 mayprocess such data. The system may transmit such data to anothercomponent, such as a part of the device manufacturer 132, for processingor additional processing of the data.

Based upon the data, the patient feedback system 410 (or anothercomponent) may determine to alter manufacturer's default settings (i.e.,configuration) of newly manufactured ICTDs, such as ICTDs 133 of FIG. 4.In other words, defaults, constants, and formulas employed by ICTDs maybe modified based upon processed population data alone or based uponprocessed population data and information regarding a specific patientof a particular ICTD.

Exemplary ICTD

FIG. 5 shows an exemplary ICTD 102 in electrical communication with apatient's heart 106 for monitoring heart activity and/or deliveringstimulation therapy, such as pacing or defibrillation therapies. TheICTD 102 is in electrical communication with a patient's heart 106 byway of three leads 108(1)-(3). To sense atrial cardiac signals and toprovide right atrial chamber stimulation therapy, the ICTD 102 iscoupled to an implantable right atrial lead 108(1) having at least anatrial tip electrode 502, which typically is implanted in the patient'sright atrial appendage. To sense left atrial and ventricular cardiacsignals and to provide left chamber pacing therapy, the ICTD 102 iscoupled to a coronary sinus lead 108(2) designed for placement in thecoronary sinus region via the coronary sinus. The coronary sinus lead108(2) positions a distal electrode adjacent to the left ventricleand/or additional electrode(s) adjacent to the left atrium. An exemplarycoronary sinus lead 108(2) is designed to receive atrial and ventricularcardiac signals and to deliver left ventricular pacing therapy using atleast a left ventricular tip electrode 504, left atrial pacing therapyusing at least a left atrial ring electrode 506, and shocking therapyusing at least a left atrial coil electrode 508.

The ICTD 102 is also shown in electrical communication with thepatient's heart 106 by way of an implantable right ventricular lead108(3) having, in this implementation, a right ventricular tip electrode510, a right ventricular ring electrode 512, a right ventricular (RV)coil electrode 514, and an SVC coil electrode 516. Typically, the rightventricular lead 108(3) is transvenously inserted into the heart 102 toplace the right ventricular tip electrode 510 in the right ventricularapex so that the RV coil electrode 514 will be positioned in the rightventricle and the SVC coil electrode 516 will be positioned in thesuperior vena cava Accordingly, the right ventricular lead 108(3) iscapable of receiving cardiac signals, and delivering stimulation in theform of pacing and shock therapy to the right ventricle.

FIG. 6 shows an exemplary, simplified block diagram depicting variouscomponents of the ICTD 102. The ICTD 102 can be configured to performone or more of a variety of functions including, for example, monitoringheart activity, monitoring patient activity, and treating fast and slowarrhythmias with stimulation therapy that includes cardioversion,defibrillation, and pacing stimulation. While a particular multi-chamberdevice is shown, it is to be appreciated and understood that this isdone for illustration purposes.

The circuitry is housed in housing 600, which is often referred to asthe “can”, “case”, “encasing”, or “case electrode”, and may beprogrammably selected to act as the return electrode for unipolar modes.Housing 600 may further be used as a return electrode alone or incombination with one or more of the coil electrodes for shockingpurposes. Housing 600 further includes a connector (not shown) having aplurality of terminals 602, 604, 606, 608, 612, 614, 616, and 618 (shownschematically and, for convenience, the names of the electrodes to whichthey are connected are shown next to the terminals).

To achieve right atrial sensing and pacing, the connector includes atleast a right atrial tip terminal (A_(R) TIP) 602 adapted for connectionto the atrial tip electrode 502. To achieve left chamber sensing,pacing, and shocking, the connector includes at least a left ventriculartip terminal (V_(L) TIP) 604, a left atrial ring terminal (A_(L) RING)606, and a left atrial shocking terminal (A_(L) COIL) 608, which areadapted for connection to the left ventricular ring electrode 504, theleft atrial ring electrode 506, and the left atrial coil electrode 508,respectively. To support right chamber sensing, pacing, and shocking,the connector includes a right ventricular tip terminal (V_(R) TIP) 612,a right ventricular ring terminal (V_(R) RING) 614, a right ventricularshocking terminal (RV COIL) 616, and an SVC shocking terminal (SVC COIL)618, which are adapted for connection to the right ventricular tipelectrode 510, right ventricular ring electrode 512, the RV coilelectrode 514, and the SVC coil electrode 516, respectively.

At the core of the ICTD 102 is a programmable microcontroller 620 thatcontrols various operations of the ICTD, including cardiac monitoringand stimulation therapy. Microcontroller 620 includes a microprocessor(or equivalent control circuitry), RAM and/or ROM memory, logic andtiming circuitry, state machine circuitry, and I/O circuitry.Microcontroller 620 includes the ability to process or monitor inputsignals (data) as controlled by a program code stored in a designatedblock of memory. Any suitable microcontroller 620 may be used. The useof microprocessor-based control circuits for performing timing and dataanalysis functions are well known in the art.

For discussion purposes, microcontroller 620 is illustrated as includingtiming control circuitry 632 to control the timing of the stimulationpulses (e.g., pacing rate, atrio-ventricular (AV) delay, atrialinterconduction (A-A) delay, or ventricular interconduction (V-V) delay,etc.) as well as to keep track of the timing of refractory periods,blanking intervals, noise detection windows, evoked response windows,alert intervals, marker channel timing, and so on. Microcontroller 220may further include various types of cardiac condition detectors 634(e.g., an arrhythmia detector, a morphology detector, etc.) and varioustypes of compensators 636 (e.g., orthostatic compensator, syncoperesponse module, etc.). These components can be utilized by the device102 for determining desirable times to administer various therapies. Thecomponents 632-636 may be implemented in hardware as part of themicrocontroller 620, or as software/firmware instructions programmedinto the device and executed on the microcontroller 620 during certainmodes of operation.

The ICTD 102 further includes an atrial pulse generator 622 and aventricular pulse generator 624 that generate pacing stimulation pulsesfor delivery by the right atrial lead 108(1), the coronary sinus lead108(2), and/or the right ventricular lead 108(3) via an electrodeconfiguration switch 626. It is understood that in order to providestimulation therapy in each of the four chambers of the heart, theatrial and ventricular pulse generators, 622 and 624, may includededicated, independent pulse generators, multiplexed pulse generators,or shared pulse generators. The pulse generators 622 and 624 arecontrolled by the microcontroller 620 via appropriate control signals628 and 630, respectively, to trigger or inhibit the stimulation pulses.

The electronic configuration switch 626 includes a plurality of switchesfor connecting the desired electrodes to the appropriate I/O circuits,thereby providing complete electrode programmability. Accordingly,switch 626, in response to a control signal 642 from the microcontroller620, determines the polarity of the stimulation pulses (e.g., unipolar,bipolar, combipolar, etc.) by selectively closing the appropriatecombination of switches (not shown).

Atrial sensing circuits 644 and ventricular sensing circuits 646 mayalso be selectively coupled to the right atrial lead 108(1), coronarysinus lead 108(2), and the right ventricular lead 108(3), through theswitch 626 to detect the presence of cardiac activity in each of thefour chambers of the heart. Accordingly, the atrial (ATR. SENSE) andventricular (VTR. SENSE) sensing circuits, 644 and 646, may includededicated sense amplifiers, multiplexed amplifiers, or sharedamplifiers. Each sensing circuit 644 and 646 may further employ one ormore low power, precision amplifiers with programmable gain and/orautomatic gain control, bandpass filtering, and a threshold detectioncircuit to selectively sense the cardiac signal of interest. Theautomatic gain control enables the ICTD 102 to deal effectively with thedifficult problem of sensing the low amplitude signal characteristics ofatrial or ventricular fibrillation. Switch 626 determines the “sensingpolarity” of the cardiac signal by selectively closing the appropriateswitches. In this way, the clinician may program the sensing polarityindependent of the stimulation polarity.

The outputs of the atrial and ventricular sensing circuits 644 and 646are connected to the microcontroller 620 which, in turn, is able totrigger or inhibit the atrial and ventricular pulse generators 622 and624, respectively, in a demand fashion in response to the absence orpresence of cardiac activity in the appropriate chambers of the heart.The sensing circuits 644 and 646 receive control signals over signallines 648 and 650 from the microcontroller 620 for purposes ofcontrolling the gain, threshold, polarization charge removal circuitry(not shown), and the timing of any blocking circuitry (not shown)coupled to the inputs of the sensing circuits 644 and 646.

Cardiac signals are also applied to inputs of an analog-to-digital (A/D)data acquisition system 652. The data acquisition system 652 isconfigured to acquire intracardiac electrogram signals, convert the rawanalog data into a digital signal, and store the digital signals forlater processing and/or telemetric transmission to an external device654. The data acquisition system 652 is coupled to the right atrial lead108(1), the coronary sinus lead 108(2), and the right ventricular lead108(3) through the switch 626 to sample cardiac signals across any pairof desired electrodes.

The data acquisition system 652 may be coupled to the microcontroller620, or other detection circuitry, to detect an evoked response from theheart 106 in response to an applied stimulus, thereby aiding in thedetection of “capture”. Capture occurs when an electrical stimulusapplied to the heart is of sufficient energy to depolarize the cardiactissue, thereby causing the heart muscle to contract. Themicrocontroller 620 detects a depolarization signal during a windowfollowing a stimulation pulse, the presence of which indicates thatcapture has occurred. The microcontroller 620 enables capture detectionby triggering the ventricular pulse generator 624 to generate astimulation pulse, starting a capture detection window using the timingcontrol circuitry 632 within the microcontroller 620, and enabling thedata acquisition system 652 via control signal 656 to sample the cardiacsignal that falls in the capture detection window and, based on theamplitude, determines if capture has occurred.

The microcontroller 620 is further coupled to a memory 660 by a suitabledata/address bus 662, wherein the programmable operating parameters usedby the microcontroller 620 are stored and modified, as required, inorder to customize the operation of the implantable device 102 to suitthe needs of a particular patient. Such operating parameters define, forexample, pacing pulse amplitude, pulse duration, electrode polarity,rate, sensitivity, automatic features, arrhythmia detection criteria,and the amplitude, waveshape and vector of each shocking pulse to bedelivered to the patient's heart 106 within each respective tier oftherapy. With memory 660, the ICTD 102 is able to sense and store arelatively large amount of data (e.g., from the data acquisition system652), which may transmitted to the external network of knowledge workersfor subsequent analysis.

Operating parameters of the ICTD 102 may be non-invasively programmedinto the memory 660 through a telemetry circuit 664 in telemetriccommunication with an external device, such as a programmer 110 or localtransceiver 112. The telemetry circuit 664 advantageously allowsintracardiac electrograms and status information relating to theoperation of the device 102 (as contained in the microcontroller 620 ormemory 660) to be sent to the external devices.

The ICTD 100 can further include one or more physiologic sensors 670,commonly referred to as “rate-responsive” sensors because they aretypically used to adjust pacing stimulation rate according to theexercise state of the patient. However, the physiological sensor 670 mayfurther be used to detect changes in cardiac output, changes in thephysiological condition of the heart, or diurnal changes in activity(e.g., detecting sleep and wake states, detecting position or posturalchanges, etc.). Accordingly, the microcontroller 620 responds byadjusting the various pacing parameters (such as rate, AV Delay, V-VDelay, etc.) at which the atrial and ventricular pulse generators, 622and 624, generate stimulation pulses. While shown as being includedwithin the device 102, it is to be understood that the physiologicsensor 670 may also be external to the device 102, yet still beimplanted within or carried by the patient. Examples of physiologicsensors that may be implemented in device 102 include known sensorsthat, for example, sense respiration rate and/or minute ventilation, pHof blood, ventricular gradient, and so forth.

The ICTD 102 additionally includes a battery 676 that provides operatingpower to all of circuits shown in FIG. 2. If the device 102 isconfigured to deliver pacing or shocking therapy, the battery 676 iscapable of operating at low current drains for long periods of time(e.g., preferably less than 10 μA), and is capable of providinghigh-current pulses (for capacitor charging) when the patient requires ashock pulse (e.g., preferably, in excess of 2 A, at voltages above 2 V,for periods of 10 seconds or more). The battery 676 also desirably has apredictable discharge characteristic so that elective replacement timecan be detected. As one example, the device 102 employs lithium/silvervanadium oxide batteries.

The ICTD 102 can further include magnet detection circuitry (not shown),coupled to the microcontroller 620, to detect when a magnet is placedover the device 102. A magnet may be used by a clinician to performvarious test functions of the device 102 and/or to signal themicrocontroller 620 that the external programmer is in place to receiveor transmit data to the microcontroller 620 through the telemetrycircuits 664.

The ICTD 102 further includes an impedance measuring circuit 678 that isenabled by the microcontroller 620 via a control signal 680. Uses for animpedance measuring circuit 678 include, but are not limited to, leadimpedance surveillance during the acute and chronic phases for properlead positioning or dislodgement; detecting operable electrodes andautomatically switching to an operable pair if dislodgement occurs;measuring respiration or minute ventilation; measuring thoracicimpedance for determining shock thresholds; detecting when the devicehas been implanted; measuring stroke volume; and detecting the openingof heart valves, etc. The impedance measuring circuit 678 isadvantageously coupled to the switch 626 so that any desired electrodemay be used.

In the case where the device 102 is intended to operate as animplantable cardioverter/defibrillator (ICD) device, it detects theoccurrence of an arrhythmia, and automatically applies an appropriateelectrical shock therapy to the heart aimed at terminating the detectedarrhythmia. To this end, the microcontroller 620 further controls ashocking circuit 682 by way of a control signal 684. The shockingcircuit 682 generates shocking pulses of low (up to 0.5 Joules),moderate (0.5-10 Joules), or high energy (11 to 40 Joules), ascontrolled by the microcontroller 620. Such shocking pulses are appliedto the patient's heart 106 through at least two shocking electrodes, andas shown in this implementation, selected from the left atrial coilelectrode 508, the RV coil electrode 514, and/or the SVC coil electrode516. As noted above, the housing 600 may act as an active electrode incombination with the RV coil electrode 514, or as part of a splitelectrical vector using the SVC coil electrode 516 or the left atrialcoil electrode 508 (i.e., using the RV electrode as a common electrode).

Cardioversion shocks are generally considered to be of low to moderateenergy level (so as to minimize pain felt by the patient), and/orsynchronized with an R-wave and/or pertaining to the treatment oftachycardia. Defibrillation shocks are generally of moderate to highenergy level (i.e., corresponding to thresholds in the range of 5-40Joules), delivered asynchronously (since R-waves may be toodisorganized), and pertaining exclusively to the treatment offibrillation. Accordingly, the microcontroller 620 is capable ofcontrolling the synchronous or asynchronous delivery of the shockingpulses.

The ICTD 102 may further be designed with the ability to supporthigh-frequency wireless communication, typically in the radio frequency(RF) range. As illustrated in FIG. 2, the can 600 may be configured witha secondary, isolated casing 690 that contains circuitry for handlinghigh-frequency signals. Within this separate case 690 are ahigh-frequency transceiver 692 and a diplexer 694. High-frequencysignals received by a dedicated antenna, or via leads 108, are passed tothe transceiver 692. Due to the separate casing region 690, thetransceiver handles the high-frequency signals in isolation apart fromthe cardiac therapy circuitry. In this manner, the high-frequencysignals can be safely handled, thereby improving telemetrycommunication, without adversely disrupting operation of the otherdevice circuitry.

Exemplary Computing Device

FIG. 7 shows an exemplary computing device 700 employed in the computingsystems of the cardiac therapy network architecture 100. It includes aprocessing unit 702 and memory 704. Memory 704 includes both volatilememory 706 (e.g., RAM) and non-volatile memory 708 (e.g., ROM, EEPROM,Flash, disk, optical discs, persistent storage, etc.). An operating andsystem and various application programs 710 are stored in non-volatilememory 708. When a program is running, various instructions are loadedinto volatile memory 706 and executed by processing unit 702. Examplesof possible applications that may be stored and executed on thecomputing device include the knowledge worker specific applications 206shown in FIG. 2.

The computing device 700 may further be equipped with a network I/Oconnection 720 to facilitate communication with a network. The networkI/O 720 may be a wire-based connection (e.g., network card, modem, etc.)or a wireless connection (e.g., RF transceiver, Bluetooth device, etc.).The computing device 700 may also include a user input device 722 (e.g.,keyboard, mouse, stylus, touch pad, touch screen, voice recognitionsystem, etc.) and an output device 724 (e.g., monitor, LCD, speaker,printer, etc.).

Various aspects of the methods and systems described throughout thisdisclosure may be implemented in computer software or firmware ascomputer-executable instructions. When executed, these instructionsdirect the computing device (alone, or in concert with other computingdevices of the system) to perform various functions and tasks thatenable the cardiac therapy network architecture 100.

Historical Cardiac-Status-and-Treatment Information

The data collected by one or more embodiments includes historicalcardiac-status-and-treatment information for a specific patient. It mayalso include such information about multiple patients of a patentpopulation. Historical cardiac-status-and-treatment informationexpressly includes information about patients (e.g., demographic data);cardiac status; cardiac treatment; cardiac equipment; etc.

The following are examples of data parameters that may be part of thehistorical cardiac-status-and-treatment information. These parametersmay be used to correlate patient population data with a specificpatient. This list is not exhaustive. Of course, other parameters may beused.

Examples of patient-specific parameters:

-   -   cardiac monitoring data and statistics;    -   cardiac treatment data and statistics;    -   ICTD model and serial number;    -   ICTD battery status;    -   waveform of treatment;    -   shocking protocol;    -   patient age;    -   patient gender;    -   patient activity patterns;    -   patient weight;    -   patient ethnic/nationality;    -   patient genetics;    -   patient temporal cycles;    -   patient sleep/wake patterns; and    -   patient medications.        Operation

FIG. 8 shows methodological implementation of the exemplary feedbackloop technology performed by the cardiac therapy network architecture100 (or some portion thereof) and/or the patient feedback architecture400 (or some portion thereof). This methodological implementation may beperformed in software, hardware, or a combination thereof.

At 810 of FIG. 8, data is collected by a patient's ICTD. It isfield-collected. This means that the data collected is primarily outsideof the laboratory setting. Primarily, it is outside the controlledenvironments of the hospital or doctor's office. Although some of thedata may have been collected during a programming session, the bulk iscollected while the patient performs her normal daily activities.

At 812, this field-collected data is transmitted in accordance with thecardiac therapy network architecture 100.

At 814 of FIG. 8, the patient feedback architecture gathers thefield-collected data regarding a specific patient. At 816, it gathersdata about multiple patients in a patient population.

At 818, the patient feedback architecture analyzes the data. During suchanalysis, the patient feedback architecture searches for patterns in thedata; correlations amongst the data; and the like. It uses techniquesgenerally called knowledge discovery in databases (KDD). In thevernacular of those of ordinary skill in the art, these techniques arecollectively called “data mining.”

For example, statistical calculation may be performed to determine thebest course of ICTD treatment for a patient having a particular age,gender, heart rate, etc.

Clinical trials may be performed since field results can be tracked andanalyzed. For example, a medical team may experiment across a patientpopulation with different rescue waveforms to determine which is best.Currently, biphasic waveform is used to defibrillate a patient. There isa belief that the leading edge of the biphasic waveform is the cause ofgreat pain. Conventional techniques do not allow for the gatheringexperimental waveform data to determine if other waveforms may be moreeffective and/or less painful. Other waveforms may be stepped-up orrounded. It may be triphasic.

At 820, the treatment of a patient may be changed based upon theanalysis of the patient's own data, of the patient population data, or acombination of both. This may be done automatically or manually. Asignal may be sent back to the ICTD to alter the patient's treatment.For example, it may change the energy level used to rescue a patientsuffering cardiac fibrillation. Alternatively, analysis of patientpopulation data may lead to altered design and/or default programming ofICTDs.

The process ends at 822.

Conclusion

Although the invention has been described in language specific tostructural features and/or methodological steps, it is to be understoodthat the invention defined in the appended claims is not necessarilylimited to the specific features or steps described. Rather, thespecific features and steps are disclosed as preferred forms ofimplementing the invention.

1. A method comprising: administering cardiac therapy to a plurality ofpatients via a plurality of implanted cardiac therapy devices; storingdata regarding the therapy at the respective implanted cardiac therapydevices; collecting the data from the plurality of implanted cardiactherapy devices; processing the collected data to discover patterns,relationships, or correlations between such data; modifying therapy ofone or more patients based upon the patterns, relationships, orcorrelations.
 2. A method as recited in claim 1, wherein the processingcomprises knowledge discovery in database (KDD).
 3. A method as recitedin claim 1, wherein the data comprises historicalcardiac-status-and-treatment information.
 4. A method as recited inclaim 1, wherein the data comprises one or more of the followingparameters: cardiac monitoring data and statistics; cardiac treatmentdata and statistics; ICTD model and serial number; ICTD battery status;waveform of treatment; shocking protocol; patient age; patient gender;patient activity patterns; patient weight; patient ethnic/nationality;patient genetics; patient temporal cycles; patient sleep/wake patterns;and patient medications.
 5. A method comprising: administering cardiactherapy to a plurality of patients; gathering data from each patientregarding the therapy and the response to the therapy; collecting datarelated to such therapy and the response from the plurality of patients;analyzing the data to determine appropriate therapies; and modifyingtherapy of one or more patients based upon the patterns, relationships,or correlations.
 6. A method as recited in claim 5 further comprisingadjusting therapies for one or more patients in response to theanalyzing.
 7. A method as recited in claim 5, wherein the analyzingcomprises statistically processing the collection of data to discoverpatterns, relationships, or correlations between such data.
 8. A methodas recited in claim 5 wherein the collecting comprises field-collectingthe collection of data from a plurality of implantable cardiac devices(ICTDs).
 9. A method as recited in claim 5, wherein the data compriseshistorical cardiac-status-and-treatment information.
 10. A method asrecited in claim 5, wherein the data comprises one or more of thefollowing parameters: cardiac monitoring data and statistics; cardiactreatment data and statistics; ICTD model and serial number; ICTDbattery status; waveform of treatment; shocking protocol; patient age;patient gender; patient activity patterns; patient weight; patientethnic/nationality; patient genetics; patient temporal cycles; patientsleep/wake patterns; and patient medications.
 11. A system comprising: aplurality of implantable cardiac therapy devices configured to beimplanted in corresponding patients; a central database; acommunications link configured to facilitate communications between thecentral database and the plurality of implantable cardiac therapydevices; wherein the database is further operative to receive datarelating to therapy administered to the patients by the plurality ofimplantable cardiac therapy devices, process the collection of data todiscover patterns, relationships, or correlations between such data, andto modify therapy of one or more of the implantable cardiac therapydevices in response to the patterns, relationships, or correlationsbetween the data.
 12. A system as recited in claim 11, wherein the datacomprises historical cardiac-status-and-treatment information.
 13. Asystem as recited in claim 11, wherein the data comprises historicalcardiac-status-and-treatment information of a plurality of patients. 14.A system as recited in claim 11, wherein the data comprises one or moreparameters selected from a group of parameters consisting of: cardiacmonitoring data and statistics; cardiac treatment data and statistics;ICTD model and serial number; ICTD battery status; waveform oftreatment; shocking protocol; patient age; patient gender; patientactivity patterns; patient weight; patient ethnic/nationality; patientgenetics; patient temporal cycles; patient sleep/wake patterns; patientmedications.